You seem to be trying to pit SVG against Flash, though I'm not sure why. My point about indexing SVG has nothing to do with whether Flash or SVG is "better", or even the differences between the formats; in fact, the only reason I mentioned Flash is by way of comparison with relative usage on the Web, and by any metric, Flash is far more widely used currently. If you prefer Flash, by all means use Flash. My blog post was about technical details of indexing SVG in search engines... in that context, I'm only interested in Flash if there are things we can learn from it to accomplish that goal, even negative examples such as the ones you're indicating with the contextless content.

But when I talk about SVG having text-as-text, and metadata attributes and elements, I am specifically talking about the human- and machine-readable content, not about the element and attribute names or geometric values. You may think that doesn't get you very far, but I strongly disagree. Also, the use of ARIA attributes can add an additional semantic layer on top of the structure and textual content, to make it even more accessible and indexible. In most cases, I wouldn't consider an image of an animal as an information graphic (though that depends... an anatomical drawing might be somewhat indexible).

As one of the folks on the SVG Working Group, defining the SVG specification, I can assure you that it is not an abuse of the format to use text content, or metadata; in fact, it's considered a best practice, and encouraged explicitly. It may not be to your taste, but it suits many people very well. HTML is not the only information-rich structured data format, nor often is it the best one... it is almost certainly the most popular, and not just on the Web, but it's not very good at describing graphics, or math, or any number of other areas.

(As an aside, just to clarify your misconception, SVG does have timelines and declarative animation, and SVG Tiny 1.2 for mobile devices also has audio and video; on the desktop platform, we rely on HTML for audio and video, since SVG integrates well with HTML and we don't need to duplicate that functionality. One of SVG's strengths is that it builds on, integrates, and enhances other web standards people already know, like HTML, CSS, DOM, Javascript, etc.)

I agree, for some value of the word "dynamic".

Scripted dynamic content often injects new content into the DOM, or replaces or removes existing content. In extreme (but common) cases, the majority of content is dynamically inserted into the DOM clientside, which makes it a very poor candidate for indexing. Without existing structure, hyperlinks, and textual content (text, metadata, titles, descriptions, etc.), search engines have little to go on.

The kind of dynamic interactive content you're talking about, using declarative markup or script that merely manipulates existing DOM content rather than changing it, already has the structure and textual content, and is thus more readily and pragmatically indexible.

It's not black and white, but the presence of script is the most simple heuristic I can think of for detecting content which is less suitable to be treated as an image, or which is expected to dramatically change. I would be satisfied if this were used as a first-pass solution on determining which SVG files would appear for image searches and which would be treated more like HTML.

I don't know enough about Flash to speak about its indexibility compared to HTML, but there are an awful lot of HTML applications which are indexed. So, I don't think it's necessarily how "static" a file is that lends itself to being indexed, but how popular and "contentful" the file or service is. The format of the file shouldn't prejudice a search engine toward or away from indexing it; each file format has its own challenges and benefits.

Okay, I'm not in a position to defend Flash (I was trying to be nice by giving it the benefit of the doubt), but SVG was designed from the bottom up as a text format, where visible text is exactly that, and while some SVGs don't contain any text or metadata, many do have a significant percentage of relevant textual data. You presume (I believe incorrectly) that the text in an SVG file is irrelevant, because you're comparing it with Flash. SVG is not Flash, and it's not necessarily used in the same way.

But even for SVG files that don't have indexible internal content, they could be treated on par with the support that Google supplies for images, where the surrounding text informs the indexing and ranking.

As for discerning when a file is an application rather than a static file, that's relatively easy... look for a script element. Many HTML files are just as "meaningless", when HTML is used for an application rather than a documents, for what that's worth.

But I'm not saying that all SVGs, today, are optimized for searching and indexing. I think we would benefit from establishing some best practices, and maybe even changing the format a bit, to make SVG files more indexible, where it makes sense to do so... for static, information-rich graphics and so forth.

The problems are real: we need a way for information graphics to be easily created in an accessible way, and we need for those graphics for be readily findable. How we get there is what I'm interested in.

Hi, Stan-

You raise a good point, but I'm not actually talking about the actual amount of content on the web, I'm talking about how it is indexed and searchable (in this case, by Google). I'm sure that there is a lot more Flash content than my rough study indicates, and I could be clearer about that in my blog post, but for the purposes of discussing the relative representation in search results, I think it's fair to say that the presence (or lack of presence) of content is distorted by how easy it is to find it through the search engine.

Ultimately, it doesn't matter how much Flash or SVG content is on the web... both should be indexed and represented in search results. How we get to that point, and how we can make is fruitful for people searching for the content, is the interesting question.

True. But it's not that onerous to apply, from what I understand. In many cases, applying is simply a formality, and is often a procedural follow-on from an informal invitation. You could be turned down, although this would be bizarre if they extended you the invitation in the first place.

But again, being an Invited Expert is not the only way you can have an effect. As others have noted, formal involvement in a Working Group can be a serious time investment, but anyone is welcome to send feedback to the appropriate public list. In fact, a Working Group is required to give a formal technical reply to any comment received on a Last Call draft.

I think that it is a pretty open process in most cases, even though this can be a challenge. It can delay or even cripple the publication of a specification, which means that the W3C can't respond to real-world market pressures as quickly as many would like. Ironically, some of the people who complain that the W3C isn't agile enough are the same ones who hold up specifications on process issues.

It's not easy reaching consensus. I'm sure that's why your own WCAG Samurai initiative is a closed process. In fact, you're pretty extreme about it:

Membership rolls will not be published, and membership is by invitation only. Don't call us; we'll call you.

But as someone deeply concerned with accessibility issues, I applaud your actions in that arena.